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Abstract. Attribute-driven software architecture design aims to pro¬ 
vide decision support by taking into account the quality attributes of 
softwares. A central question in this process is: What architecture design 
best fulfills the desirable software requirements? To answer this ques¬ 
tion, a system designer needs to make tradeoffs among several poten¬ 
tially conflicting quality attributes. Such decisions are normally ad-hoc 
and rely heavily on experiences. We propose a mathematical approach to 
tackle this problem. Game theory naturally provides the basic language: 
Players represent requirements, and strategies involve setting up coali¬ 
tions among the players. In this way we propose a novel model, called 
decomposition game (DG), for attribute-driven design. We present its 
solution concept based on the notion of cohesion and expansion-freedom 
and prove that a solution always exists. We then investigate the com¬ 
putational complexity of obtaining a solution. The game model and the 
algorithms may serve as a general framework for providing useful guid¬ 
ance for software architecture design. We present our results through 
running examples and a case study on a real-life software project. 
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1 Introduction 

Computational game theory studies the algorithmic nature of conflicting en¬ 
tities and establishes equilibria: A state of balance that minimises the negative 
effects among players. The field has attracted much attention in the recent 10-15 
years due to applications in multi-agent systems, electronic markets and social 
networks mm- In this paper, we investigate the problem of software archi¬ 
tecture design from a game theory perspective. In particular, we provide a novel 
model, called decomposition game , which captures interactions among software 
requirements and derives a software architecture through equilibria. 

The architecture of a software system lays out its basic composition. For 
softwares become larger, quality attributes such as performance, reliability, us¬ 
ability and security, play an increasingly important role. It has been a common 
belief that architecture design heavily influences the quality attributes such as 
performance, reliability, usability and security of a software system [ 23 - A ma¬ 
jor objective of architecture design is therefore the assurance of non-functional 




requirements through compositional decisions. In other words, we need to an¬ 
swer the following question: What architecture best fulfills the desirable software 
requirements? There is, however, usually no “perfect” architecture that fulfills 
every requirement. For example, performance and security are both key non¬ 
functional requirements, which may demand fast response time to the users, and 
the application of a sophisticated encryption algorithm, respectively. These two 
requirements are in intrinsic conflict, as a strong focus of one will negatively im¬ 
pact the fulfilment of the other. A main task of the software architect, therefore, 
is to balance such “interactions” among requirements, and decide on appropriate 
tradeoffs among such conflicting requirements. 

While it is a common practice to decide on software architecture designs 
through the designers’ experiences and intuition, formal approaches for archi¬ 
tecture design are desirable as they facilitate standardisation and automation 
of this process, providing rigorous guidelines, allowing automatic analysis and 
verifications [6]. Notable formal methods in software architecture include a large 
number of formal architecture description languages (ADL), which are useful 
tools in communicating and modeling architectures. However, as argued by |14j . 
industry adoptions of ADL are rare due to limitations in usability and formality. 
Other algorithmic methods for software architecture design include employing 
hierarchical clustering algorithms to decompose components based on their com¬ 
mon attributes [Hj, as well as quantifying tradeoffs between requirements jT]. 

In this paper, we propose to use computational game theory as a mathemat¬ 
ical foundation for conceptualising software architecture designs from require¬ 
ments. Our motivation comes from the following two lines of research: 

(1) . Attribute driven design (ADD) : ADD is a systematic method for software 
architecture design. The method was invented by Bass, Klein and Bachmann 
in [3] and subsequently updated and improved through a sequence of works 
Ena. The goal is to assist designers to analyse quality attribute tradeoffs and 
provide design suggestions and guidance. Inputs to ADD are functional and 
non-functional requirements, as well as design constraints; outputs to ADD are 
conceptual architectures which outline coarse-grained system compositions. The 
method involves a sequence of well-defined steps that recursively decompose a 
system to components, subcomponents, and so on. These steps are not algorith¬ 
mic: They are meant to be followed by system designers based on their experi¬ 
ence and understanding of design principles. As mentioned by the authors in j3], 
an ongoing effort is to investigate rigorous approaches in producing conceptual 
architectures from requirements, hence enabling automated design recommenda¬ 
tion under the ADD framework. To this end, we initiate a game-theoretic study 
to formulate the interactions among software requirements so that a conceptual 
architecture can be obtained in an algorithmic way. 

(2) . Coalition game theory : A coalition game is one where players exercise col¬ 
laborative strategies, and competition takes place among coalitions of players 
rather than individuals. In ADD, we can imagine each requirement is “handled” 
by a player, whose goal is to set up a coalition with others to maximise the 




collective payoff. The set of coalitions then defines components in a system de¬ 
composition which entails a software architecture. This fits into the language 
of coalition games. However, the usual axioms in coalition games specify super¬ 
additivity and monotonicity, that is, the combination of two coalitions is always 
more beneficial than each separate coalition, and the payoff increases as a coali¬ 
tion grows in size. Such assumptions are not suitable in this context as combi¬ 
nation of two conflicting requirements may result in a lower payoff. Hence a new 
game model is necessary to reflect the conflicting nature of requirements. In this 
respect, we propose that our model also enriches the theory of coalition games. 


Our contribution. We provide a formal framework which, following the ADD 
paradigm [4j, recursively decomposes a system into sub-systems; the final de¬ 
composition reveals design elements in a software architecture. The basis of the 
framework is an algorithmic realisation of ADD. A crucial task in this algorith¬ 
mic realisation is system decomposition , which derives a rational decomposition 
of an attribute primitive. 

We model system decomposition using a game, which we call decomposition 
game. The game takes into account interactions between requirements, which 
express the positive (enhancement) or negative (canceling) effects they act on 
each other. A solution concept (equilibrium) defines a rational decomposition, 
which is based on the notions of cohesion and expansion-freedom. 

We demonstrate that any such game has a solution, and a solution may 
not be unique. We also investigate algorithms that compute solutions for the 
decomposition game. Finding cohesive coalitions with maximal payoff turns out 
to be NP-hard (Thm. 13). Hence we propose a relaxed notion of k-cohesion 
for k > 1 , and present a polynomial time algorithm for finding a fc-cohesive 
solution of the game (Thm. 16). To demonstrate the practical significance our 
the framework, we implement the framework and perform a case study on a 
real-world Cafeteria Ordering System. 


Paper organisation. Section [2] introduces the formal ADD framework. Sec¬ 
tion [3] discusses decomposition game and its solution concept. Section [4] presents 
algorithms for solving decomposition games. Section [5 presents the case study. 
Section [6] discusses related works and finally Section 7] concludes with future 
works. 


2 Algorithmic Attribute Driven Design (ADD) Process 


ADD is a general framework for transforming software requirements into a con¬ 
ceptual software architecture. Pioneers of this approach introduced it through 
several well-formed, but informally-defined concepts and steps M- A natural 
question arises whether it can be made more algorithmic, which provides unbi¬ 
ased, mathematically-grounded outputs. To answer this question, one would first 
need to translate the original informal descriptions to a mathematical language. 







2.1 Software Requirements and Constraints 


Functional requirements. Functional requirements are specifications of what 
tasks the system perform (e.g. “the system must notify the user once a new email 
arrives”).A functional requirement does not stand alone; often, it acts with other 
functional requirements to express certain combined functionality (e.g. “the user 
should log in before making a booking”). Thus, a functionality may depend on 
other functionalities. We use a partial ordering (F, -<) to denote the functional 
requirements where each r £ F is a functional requirement, and r\ -< r 2 denotes 
that rq depends on r^- Note that -< is a transitive relation. 

Non-functional requirements. Non-functional requirements specify the de¬ 
sired quality attributes; ADD uses general scenarios and scenarios as their stan¬ 
dard representations. A general scenario is a high-level description on what it 
means to achieve a non-functional requirement [3]. For example, the general 
scenario “A failure occurs and the system notifies the user; the system contin¬ 
ues to perform in a degraded manner ” refers to the availability attribute. There 
has been an effort to document all common general scenarios; a rather full list 
is given in [3j. Note that a general scenario is vaguely-phrased and is meant 
to serve as a template for more concrete “instantiations” of quality attributes. 
Such “instantiations” are called scenarios. More abstractly, we use a pair (S, ss) 
to denote the non-functional requirements where S is a set of scenarios and ss 
is an equivalence relation on S, denoting the general scenario relation: q± ~ qq 
means that q± and <72 instantiates the same general scenario. 

Design constraints. Design constraints are factors that must be taken into 
account and enforce certain design outcomes. A design constraint may affect both 
functional and non-functional requirements. More abstractly, we use a collection 
of sets C C 2 fuS to denote the set of design constraints, where each set c € C 
is a design constraint. Intuitively, if two requirements ri,r 2 belong to the same 
c £ C, then they are constrained by the same design constraint c. 

Derived Functionalities. The enforcement of certain quality attributes may 
lead to additional functionalities. For example, to ensure availability, it may be 
necessary to add extra functionalities to detect failure and automatically bypass 
failed modules. Hence we introduce a derivation relation °->C S x F such that 
r4s means the functional requirement s is derived from the scenario r. 

2.2 Attribute Primitives 

The intentional outcome of ADD describes the design elements , i.e., subsystems, 
components or connectors. It is important to note that the goal of ADD is not 
the complete automation of the design process, but rather, to provide useful 
guidance. Thus, the conceptual view reveals only the organisational structure 
but not the concrete design. 


Fig. 1 . Example [I] The requirements, constraints and their relations. 



An attribute primitive is a set of design elements that collaboratively perform 
certain functionalities and meet one or more quality requirements; it is also 
the minimal combination with respect to these goals [4]. Examples of attribute 
primitives include data router, firewall, virtual machine, interpreter and so on. 
ADD prescribes a list of attribute primitives together with descriptions of their 
properties and side effects (such as in [3]). Hence, ADD essentially can be viewed 
as assigning the right attribute primitives to the right requirement combinations. 
Note also that an attribute primitive may be broken down further. 

Definition 1 (Attribute primitive). An attribute primitive is a tuple 

A = (F, S, C, A,«, M-) 

where F is a set of functional requirements, S is a set of scenarios, C C 2 FuS is 
a set of design constraints, -< is the dependency relation on F. ss is the general 
scenario relation of S, and M-C S x F is a derivation relation. 

Let A = (F, S, C, H, ~, be an attribute primitive. We also need the following 
definition: 

— A requirement of A is an element in the set R := F U S. 

— For r £ F, the dependency set of r is the set f(r) := { r' £ F | r A r 7 }. 

— For r £ S, the general scenario of r is the set <?(r) := {r 7 £ S | r ss r 7 }, i.e., 

the ^-equivalence class of r. 

— For r £ R, the constraints of r is the set c(r) := {t £ C \ r £ t}. 

— For r £ S, the derived set of r is d(r) := {s £ F j r s}, and for s £ F, let 

d-\s) := {r £ S | r s} 

Definition 2 (Design element). A design element of A is a subset DC R. 
An decomposition of A is a sequence of design elements D = (Di, D 2 , ■ ■ ■ Dk) 
where k > 1 , Ui<i<fc = R, and each Di n Dj = 0 for any i 7 ^ j. 

Example 1 . Fig. [I] shows an attribute primitive A = (F, S, C, ^-») 

— F = {/ 1 , / 2 , / 3 } and S — {q ll q 2 ,q 3 } are the requirements 

— C = {ci,c 2 } where ci = { 91 , 93 },c 2 = { 91 } 

— fi -< / 2 , 9i ~ 92 , 9i ^ / 1 , 9i ^ h ,92 ^ /l, 92 t / 2 , 93 c —> / 3 . 









2.3 The ADD Procedure 


Essentially ADD provides a means for system decomposition: The entire sys¬ 
tem is treated as an attribute primitive, which is the input. At each step, the 
procedure decomposes an attribute primitive A by identifying a decomposition 
(Di,D 2 , ..., Dfc). The process then maps each resulting design element D, to an 
attribute primitive Ai = (F^, S*, C.j, —<*, 0 —>•*), which contains all elements in 
Di and may require some further requirements and constraints. Hence we require 
that Di C F, U Si and A, Q, <—>•,; are consistent with C and on 

Di, resp.; in this case we say that Ai is consistent with Di. Thus the attribute 
primitive A is decomposed into k attribute primitives Ai, A 2 , ■ ■ ■, Ak ■ On each 
Ai where 1 < i < k, the designer may choose to either terminate the process, or 
start a new step recursively to further decompose Ai . See Procedure [l] 


Procedure 1 ADD(A) (General Plan) 

1: (D i, D 2 , ..., Dk ) Decompose(A) // compute a rational decomposition of A 

2: for 1 < i < k do 

3: Ai an primitive attribute consistent with Di 

4: if Ai needs further decomposition then 

5: ADD(A) 


We point out that the ADD procedure, as presented by its original propo¬ 
nents, involves numerous additional stages other than the ones described above 
[T3] . The reason we choose this over-simplified description is that we believe these 
are the steps that could be rigorously presented, and they abstractly capture in 
a way most of the steps mentioned in the original informal description. 

The Decompose(A) operation produces a rational decomposition (D 1 ,..., Dk) 
of the input attribute primitive A that satisfies the requirements of A. We also 
note that Decompose)A) amounts to a crucial step in the ADD process, as the 
decomposition determines to a large extend how well the quality attributes are 
met. This step is also a challenging one as interactions among quality attributes 
create potential conflicts. Thus, in the next section, we define a game model 
which allows us to automate the Decompose)A) operation. 

3 Decomposition Games 

3.1 Requirement Relevance 

The Decompose (A) procedure looks for a rational decomposition that meets the 
requirements in A as much as possible. Let A = (F,S,C,-<,~,^)bean attribute 
primitive. Relevance between requirements are determined by the relations -< 

, and the constraint set C. In the following the Jaccard index J{S\,S 2 ) 






measures the similarity between two sets Si , S 2 with 


J(Si,S 2 ) 


l-Srn&l 

|5rU5 2 r 


Intuitively, the relevance of a requirement r to other requirements is influenced 
by the “links” between r and the functional, the non-functional requirements, 
as well as design constraints. 

Definition 3 (Relevance). Two requirements 77, r 2 £ R are relevant if 

— 77,77 £ F, and either d _1 (?7) (~l d~ l (r 2 ) 7^ 0 (derived from some common 
scenario), or f[r\) n f(r 2 ) 7^ 0 (relevant through dependency), or c(r 1) fl 
c(r 2 ) 7^ 0 (share some common design constraints). 

— r\,r 2 £ S, and either 77 ~ r 2 (instantiate the same general scenario), or 
d(ri) D d(r 2 ) 7^ 0 (jointly derives some functionality) or c(ri) fl c{r 2 ) 7^ 0. 

— 77 £ F, r 2 £ S, and either f(r 1) fl d(r 2 ) 7^ 0 (r\ depends on a requirement 
that is derived from r 2 ), or c(ri) fl c(r 2 ) 7^ 0. 

If two requirements are relevant, their relevance depends on overlaps between 
their derived sets, dependency sets and constraints. If two requirements are not 
relevant, then we regard them as having a negative relevance A < 0 , which 
represents a “penalty” one pays when two irrelevant requirements get in the 
same design element. 

Definition 4 . We define the relevance index <7(77,77) of r\ 7^ 77 £ R as follows: 

1 . if two functional requirements 77,77 £ F are relevant, then 

c(ri,r 2 ) = aJ(d _1 (n),d _1 (r 2 )) + / 3 J(/(n), /(r 2 )) + 7J(c(n), c(r 2 )); 

2 . if two scenarios 77, r 2 £ S are relevant, then 

^(ri,r 2 ) = / 3 J(d(n),d(r 2 )) +7J(c(ri),c(r 2 )); 

3 . If r 1 £ F and r 2 £ S are relevant, then 

cr{ri,r 2 ) = cr(r 2 ,n) = / 3 J(/(r i),d(r 2 )) + 7J(c(ri), c(r 2 )); 

4. otherwise, a(ri,r 2 ) = A 

The constants a,/ 3 ,7 are positive real numbers, that represent weights on the 
overlaps in d\,d 2 ’s generated sets, dependency sets and constraints, respectively. 
We require a+/3+7 = l. 

For simplicity, we do not include these constants in expressing the function 
a, and all subsequent notions that depend on a (thus saving us from writing 
“cr(n,r 2 ,a,/3,7, A)”). 

Example 2. Continue from A in Example |TJ To emphasise the non-functional 
requirements we give a larger weight to a, setting a = 0 . 5 , p = 0 . 4 , 7 = 
0 . 1 . We also set A = — 0 . 5 . Then cr(ri,r 2 ) = 0.4 x | = 0.4 for any (77, r 2 ) £ 
{(< 7 i> 92), (<?3> /a)} U ({<71, q 2 } x {fi,f 2 }); cr(q 1 ,q 3 ) = 0.1 x \ = 0 . 05 ; cr(/ 1 ,/ 2 i = 
0.5 x | + 0.4 x | = 0 . 9 ; and relevance between any other pairs is — 0 . 5 . Fig. | 2 ta) 
illustrates the (positive) relevance in a weighted graph. 



3.2 Decomposition Games 


We employ notions from coalition games to define what constitutes a rational 
decomposition. In a coalition game, players cooperate to form coalitions which 
achieve certain collective payoffs [5j. 

Definition 5 (Coalition game). A coalition game is a pair (P,is) where P is 
a finite set of players, and each subset D C P is a coalition; v : 2 P —> K. is a 
payoff function associating every D C P a real value v{D) satisfying j/(0) = 0. 

This provides the set up for decompositions: Imagine a coalition game consisting 
of |R| agents as players, where each agent is in charge of a different requirement. 
The players form coalitions which correspond to sets of requirements, i.e., design 
elements. The payoff function would associate with every coalition a numerical 
value, which is the payoff gained by each member of the coalition. Therefore, 
an equilibrium of the game amounts to a decomposition with the right balance 
among all requirements - this would be regarded as a rational decomposition. 

It remains to define the payoff function. Naturally, the payoff of a coalition 
is determined by the interactions among its members. Take r\,r 2 £ D. If one 
of r\,r 2 is a functional requirement, then their interaction is defined by their 
relevance index cr(ri, r 2 ), as higher relevance means a higher level of interaction. 
Suppose now both rq, 7 '2 are scenarios (non-functional). Then the interaction 
becomes more complicated, as a quality attribute may enhance or defect another 
quality attribute. In |T2] Chapter 14], the authors identified effects acting from 
one quality attribute to another, which is expressed by a tradeoff matrix T: 

— T has dimension m x m where m is the number of general scenarios 

- For i^jG {1,... ,to}, the (z, j)-entry T id £ {-1,0,1}. 

Let gi,g 2 , ■ ■ ■ ,gm be general scenarios. T i 3 = 1 (resp. X{ 7 = —1) means g\ has a 
positive (resp. negative) effect on g 2 , T it j = 0 means no effect. E.g., the tradeoff 
matrix defined on six common quality attributes is: 



Perfo. 

Modif. 

Secur. 

Avail. 

Testa. 

Usabi. 

Performance 

0 

-1 

0 

0 

0 

-1 

Modifiability 

-1 

0 

0 

1 

1 

0 

Security 

-1 

0 

0 

1 

-1 

-1 

Availability 

0 

0 

0 

0 

0 

0 

Testability 

0 

1 

1 

1 

0 

1 

Usability 

-1 

0 

0 

0 

-1 

0 


Note that the matrix is not necessarily symmetric: The effect from g\ to <72 
may be different from the effect from <72 to g\. For example, an improvement in 
system performance may not affect security, but increasing security will almost 
always adversely impact performance, we assume that the matrix T is given 
prior to ADD; this assumption is reasonable as there is an effective map from 
any general scenario to the main quality attribute it tries to capture. We use 
this tradeoff matrix to define the interaction between two scenarios in S. 




Definition 6 (Coalitional relevance). For a coalition DC R and r C D, 

the coalitional relevance of r in D is the total relevance from r to all other 
requirements in D, i.e., p(r,D) = s^r a ( r i s )- 

Definition 7 (Effect factor). For scenarios r\, r2 in the same coalition D, the 
effect factor from r\ to r2 expresses the effect of r\ towards r2, i.e., 


e(r 1 ,r 2 ,D) = 



ifT{g{n),g{r2)) = -1 
ifT(g(r i),g(r 2 )) = 0 
ifT(g(r i),g(r 2 )) = 1 


We are now ready to define the interaction between two scenarios ri,r2 E R. 


Definition 8 (Interaction). Let n /1'2 £ R be requirements. The interaction 
between ri,r2 is simply the relevance cr(ri,r 2 ) if one o/ri,r 2 is functional; oth¬ 
erwise (both ri, 7’2 are non-functional), it is the sum of their effect factors, i.e., 


the interaction v(r\,r 2 , D) 


cr(ri,r 2 ) if{ri,r 2 } n T ^ 0 

e(ri, r 2 , D) + e(r 2 , ri, D) otherwise 


The coalition utility v(D) of any coalition D C R is defined as the sum of 
interactions among all pairs of requirements in the coalition, i.e., 

v( D )= ^2 l '(.D,r 2 , D ) 

ri^V2£D 


Definition 9 (Decomposition games (DG)). Let A = (F, S, C, —=—>■) be 

an attribute primitive. The DG G _4 is the coalition game (F U S,v) where v : 
2 FuS —^ R is the coalition utility function. 


Fig. 2. (a) Weights on the edges are relevance (function o) between requirements in 
Example [2] the diagram omits the negative weighted pairs, (b) The decomposition 
{Si, S 2 } is a solution with n(Si) = 2.5, t/(S 2 ) = 0.4. The coalition C has u{C) = —1 




(a) (b) 




































Example 3 (Coalition Utility). Continue the setting in Example [2j Let the 
general scenarios be g i = {(?i, <72} and 92 = {93}- We assume matrix T specifies 
T(gi,g 2 ) = 1 and T(g 2 ,g 4 ) = —1. Consider the coalition C = {//i, 9.3, / 3 }. We 
have: 


9 ( 91 , C) = 0.05 - 0.5 = -0.45; and p(q 3 ,C) = 0.4 + 0.05 = 0.45. 

So e{q u q 3 ,C) = -0.45 x 1 = -0.45 and e{q 3 ,q 4 ,C) = 0.45 x (-1) = -0.45. 

Thus v(qi,q 3 ,C) = —0.45 — 0.45 = —0.9. Therefore, v(C) = <r(qi,f 3 ) + 
^( 93 , fz) + (—0.9) = (-0.5) + 0.4 + (-0.9) = -1 but v{C \ { 91 }) = v({q 3 , / 3 }) = 
v(qz,fz) = 0.4; See Fig.^b). 

As it has turned out, despite the fact that matrix T indicates q± will act 
positively to q 3 , and that 91,93 have a positive (0.05) relevance, adding qi into 
the coalition of { 93 ,/ 3 } drastically decreases the coalition utility. 

3.3 Solution Concept 

We point out some major differences between decomposition and typical coalition 
games: Firstly, in coalition game theory, one normally assumes the axioms of 
superadditivity ( v(D\ U D 2 ) > v{D\) + v(D 2 )) and monotonicity {D\ C D 2 => 
< i/(D 2 )) which would obviously not hold for decomposition as players 
may counteract with each other, reducing their combined utility. Secondly, the 
typical solution concepts in coalition games (such as Pareto optimality, and 
Shapely value) focus on distribution of payoffs to each individual player assuming 
a grand coalition consisting of all players. In decomposition such a grand coalition 
is normally not desirable and the focus is on the overall payoff of each coalition 
D , rather than the individual requirements. The above differences motivate us 
to consider a different solution concept of DG G .4. At any instance of the game, 
the players form a decomposition (D 1 , D 2 ,..., Dk). We assume that the players 
may perform two collaborative strategies: 

1. Merge strategy: Two coalitions may choose to merge if they would obtain a 
higher combined payoff. 

2. Bind strategy: Players within the same coalition may form a sub-coalition if 
they would obtain a higher payoff. 

Example 4 (A Dilemma). We present an example demonstrating the dy¬ 
namics of a DG G_ 4 - This example shows a real-world dilemma: As a coalition 
pursues higher utility through expansion (merging with others), it may be bet¬ 
ter to choose a “less-aggressive” expansion strategy over the “more-aggressive” 
counterpart, even though the latter clearly brings a higher payoff. Assume the 
following situation (which is clearly plausible in an attribute primitive): 

— R = {di, d 2 , c? 3 , dr} where S = {di^d^} and di 56 d 4 . 

— We set a({d 1 ,d 2 }) = cr({di,d 3 }) = cr({d 2 ,d 3 }) = 0.1, and a({d 2 ,d 4 }) = 0.5. 

— The tradeoff matrix indicates T(g(di),g(d 4 )) = 0, T(g(d 4 ),g(di)) = —1. 

— And, di and d 4 are irrelevant, namely er(<ii, d 4 ) = A = —0.7. 


Suppose we start with the decomposition {S = {d±, d 2 }, { 0 ^ 3 }, {^ 4 }}- Then v(S) = 
p(di,d 2 ,S) = u{di,d 2 ,S) = 0.1. Coalition S has two merge strategies: 

(1) For Si = SU {d 3 }: u(di,d 2 ,Si) = a(di,d 2 ) = 0.1, v{di, d 3 , Si) = cr(di, d 3 ) = 
0.1, v{d 2 , d 3 , Si) = a(d 2 , d 3 ) =0.1. Thus i/(5i) = 0.3. 

( 2 ) For S 2 = S'U{d 4 }: v(di,di, S 2 )=e{d 3 , di, S 2 ) = — 0.7+0.5 = — 0 . 2 , i/(di,d 2 , S 2 ) = 
cr(di, d 2 ) =0.1 , v(d 2 , di, S 2 ) = cj(d 2 ,di) = 0.b. Hence v(S 2 ) =0.1—0.2+0.5 = 0.4 

Merging with {djJ clearly results in a higher payoff for the combined coalition. 
However, if this merge happens, as ^({^ 2 ,^ 4 }) = 0.5 > v(S 2 ) = 0.4, d 2 and d 3 
would choose to bind together, hence leaving S 2 . This would be undesirable if 
d\ is a critical non-functional requirement for d 2 . 

Example [4] shows that a solution concept would be a decomposition where no 
“expansion” nor “crumbling” occur to any coalition. Formally, we define the 
following solution concepts: 

Definition 10 (Solution). Let D — (D 1 ,... ,Dj.) be a decomposition of A. 

1. A coalition D C R is cohesive if for all CCD, v{C) < v{D); D is cohesive 
if so is every Di. 

2. A coalition Di is expansion-free with respect to D if max{^(Di), u(Dj)} > 
v(Di U Dj); D is expansion-free if so is every Di. 

A solution of a DG is a decomposition that is both cohesive and expansion-free. 

Example 5 (Solution). Continue from Example [3j the utilities for 

Si = {qi,q 2 , /1 , /2 } and S 2 = {q 3 , f 3 } are: 


- Si: v{qi,q 2 ,Si) = 0, v{qi,fi,Si) = p{q 1 ,f 2 l S 1 ) = v(q 2 ,fi,Si) = 0.4, 
v(qi,f 2 , Si) = 0.4, u(fi,f 2 , = 0.9. Thus u(Si) =0.4x4+ 0.9 = 2.5 

- S 2 : u>(q 3 ,f 3 ,S 2 ) = 0.4. Thus v(S 2 ) = 0.4 

Both Si and S 2 are cohesive. Furthermore, we have v(qi,q 3 , R) =0.75-1.05 = —0.3 
and v{q 2 ,q 3 ,R) = 0.2-1.05 = -0.85. Thus ^(R) =2.9—0.5x6—0.85—0.3 = —1.45. 
Consequently, {Si, S 2 } is also expansion-free, and is thus a solution of the game. 


A solution of a DG corresponds to a rational decomposition of the at- 

any attribute primitive admits a 


tribute primitive A. As shown by Thm. 11 


solution, and rather expectedly, a solution may not be unique. 

Theorem 11 (Solution Existence). There exists a solution in any DG G^. 


Proof. We show existence of a solution by construction. Let {D\,D 2 ,... ,Dk) be 
a longest sequence such that for any i = 1 ,..., k, Di is a minimal coalition with 
maximal utility in R \ {Di, ..., D;_i} (i.e., VD C R \ {Di, ..., D.;_ 1 } : z'(Di) > 
v(D) and VD C Di : v(Di) > v(D)). 

We claim that D = (£> 1; ..., D}.) is a solution in G'^. Indeed, for any 
1 < * < fc, any proper subset of Di would have payoff strictly smaller than 
v{Di) by minimality of Di. Thus D is cohesive. Moreover, if v(D * U Dj) > 
min {v(Di), is(Dj)} for some i 7 ^ j , then D m i n uj\ does not have maximal utility 
in R \ {D 1 ,..., D rnin ii j \-[}. Hence D is expansion-free. □ 



Proposition 12. The solution of a DG may not be unique. 


Proof. Let A = (F, S, C, 0 —>■) be an attribute primitive where S = 0 and 

F = {di, d 2 , ..., cfe}. We may define C, -<, w, =->■ in such a way that 

- For all {i,j} C {1,2,3,4} and {i,j} C {4,5,6}, i ± j => v({di,dj}) = 0.1 

— For all i € {1,2,3}, j £ {5,6}, v({di,dj}) = —0.1 

Consider C = {C 1 = {di, d 2 , d 3 }, C 2 = {<4, d 5 , d 6 }} and D = {D 1 = {di,d 2 ,d 3 ,d^}, 
D 2 = {(^ 5 ,dg}}. Note that v(C\) = 0.3 and v(C 2 ) = 0.3; C is cohesive and 
C is expansion-free as ^(F) = 0.3 = z'(C'i). Note also that v(D{) = 0.6 and 
v{D 2 ) = 0.1; D is cohesive and D is expansion-free as v(D\) > v(V) □ 

4 Solving Decomposition Games 

Based on our game model, the operation Decompose^) in Procedure[l]is reduced 
to the following DG problem: 

INPUT: An attribute primitive A = (F, S, C, -<,«, 

OUTPUT: A solution D = (Di,D 2 , ..., Dk) of the game Ga 
Here, we measure computational complexity with respect to the number of re¬ 
quirements in F U S. The proof of Theorem [Tl] already implies an algorithm for 
solving the DG problem: check all subsets of R to identify a minimal set with 
maximal utility; remove it from R and repeat. However, it is clear that this algo¬ 
rithm takes exponential time. We will demonstrate below that a polynomial-time 
algorithm for this problem is, unfortunately, unlikely to exist. 

We consider the decision problem DG_D: Given A and a number w > 0, is 
there a solution D of Ga in which the highest utility of a coalition reaches w ? 
Recall that the payoff function v of Ga is defined assuming constants a, [3 ,7 > 0 
and A < 0. The theorem below holds assuming A < — 7 . 

Theorem 13. The DG_D problem is NP-hard. 

Proof. The proof is via a reduction from the maximal clique problem, which 
is a well-known NP-hard problem. Given an undirected graph H = {V,E ) 1 we 
construct an attribute primitive A such that any cohesive coalition in Ga reveals 
a clique in H. Suppose V = {1, 2,..., n}. The requirements of A consist of n 2 
scenarios: R = S := {a^.j' | 1 <i<n, 1 <i'<n}. In particular, all requirements 
are non-functional. We define an edge relation E' on S such that 

1. (i,j) £ E iff (a h i/. ajj/) £ E' for some 1 < i' < n and 1 < j' < n 

2. If (a*,*/, ajji) £ E' then ,aj t y>) £ E' for any ^ 

3. Any Ojy is attached to at most one edge in E 1 . 

Note that such a relation E' exists as any node i £ V is only connected 
with at most n — 1 other nodes in H. Intuitively, a set of requirements A, = 
{ 0 , 7 ,..., ai tn } serves as a “meta-node” and corresponds to the node i in H. In 
constructing A. we may define the general scenarios in such a way that 


- T(g(a i j 1 ) 1 g(a i j 2 )) = 0 for any 1 < i < n and j i ± j 2 . 

- T ( 9 {aii ,ji),5(0*2,32)) = - 1 for an y (71E2) i E. 

- T (9(ai ltjl ),g(a i 2 j 2 )) = 1 for any (, a iujl ,a i 2 j 2 ) G E' 

- T (ff( a nji)>5(ai2,i2)) = 0 for an y (EE2) £ £ but {a iuJ 1 ,a i 2 j 2 ) £ E' 


For every 1 < i < n and 1 < j < j' < n, put in a constraint Ci(j,j r ) = Ojj/}. 
Thus the relevance between ctjj and aqy is 




|cKi) n c(ay.y )| 


|c(oij) U c(oi ii7 -/)| 2(n-l) 

Furthermore if * 7^ then for any j,j’ we set = A. Suppose 

17 = {zi,..., E} induces a complete subgraph of H. We define the meta-clique 
coalition of 17 as 

D u = 1 J Ai i 

i<j<i 


By the above definition, for any 1 < s <t <£, take j, j’ such that (ayj, £ E'. 


w(i s ,i t ,Du) 


£{O’is,j ; Ejj ) T ,j' , Ejj ) 
PiO’isJ J Ejj) T pf-^i, ,j ': E[/) 


( 71 - 1 ) 


7 


2(n — 1) 


+ (ra — 1) x 


7 


2(n — 1) 


= 7 


Thus i'(Du) = "("-Ft _ taking out any element from Djj results in a strict 
decrease in utility, and hence Djj is cohesive. 

Now take any coalition DC. R that contains two requirements ayy, «yy such 
that ( 1 , j) ^ E. Let s = |AjHE| and 1 = \AjC\D\. Note also that = A 

for any ayy/ G A; n E. Therefore we have 

v{D) — v[D \ {ajj/}) < 7 + 2 w(ajj>,ai'ii,D) x s < 7 + 2 A + 7 = 2 (A + 7) < 0 


The last inequality above is by assumption that A < — 7 . Thus D is not cohesive. 

By the above argument, a coalition DC R is cohesive in Gy 1 iff D is the 
meta-clique coalition Du for some clique U in H. Furthermore, a decomposition 
D = (Ei, D 2 , ■ ■ ., Dk) is a solution in Gy 1 iff V can be partitioned into sets 
Ei,..., Uk where each Ej is a clique, and E,; = Djj. for all 1 <i<k. In particular, 
H has a clique with l nodes if and only if Ga has a solution that contains a 
coalition whose utility reaches . This finishes the reduction. □ 

Theorem [j~3| shows that, in a sense, identifying a “best” solutions in a DG Ga is 
hard. The main difficulty comes from the fact that one would examine all subsets 
of players to find an optimal cohesive coalition. This calls for a relaxed notion of 
a solution that is computationally feasible. To this end we introduce the notion 
of k-cohesive coalitions. Fix k G N and enforce this rule: Binding can only take 
place on k or less players. That is, a coalition C is k-cohesive whenever v{C) is 
greater than the utility of any subsets with at most k players. 

Definition 14. Fix k G N. In a DG Ga = (FUS, v), we say a coalition D C FuS 
is fc-cohesive if v{D') < z/(E) for all D' C D with |E'| < k. An decomposition 
D is fc-cohesive if every coalition in D is k-cohesive; if D is also expansion-free, 
then it is a fc-coliesive solution of the game Ga ■ 








Remark. In a sense, the value k in the above definition indicates a level of 
expected cohesion in the decomposition process. A higher value of k implies less 
restricted binding within any coalition, which results in higher “sensitivity” of 
design elements to conflicts. In a software tool which performs ADD based on 
DG, the level k may be used as an additional parameter. 


Procedure 2 DGame(A, k) 

INPUT: Attribute primitive A, k > 0 
OUTPUT: Attribute Decomposition D 
1: Df- Cohesives(A, k) 

2: Combine «— true 
3: while Combine do 
4: Combine «— false 

5: for (D, D') G D 2 , D ^ D' do 

6: if v(D' U D ) > u{D) and u(D' U D) > v(D') then 

7: D «— D' U D and remove D' from D 

8: Combine «— true 

9: return D 


Procedure 3 Cohesive(_4, k) 

INPUT: Attribute primitive A, k > 0 
OUTPUT: Attribute Decomposition D 
1: D<-[],R<- FUS 
2: while |A| > 0 do 

3: Si— ma x(R, k) // compute a maximally fc-cohesive coalition 

4: R <— R \ S 

5: D «— [D. S} 

6: return D 


Let I? be a set of requirements. A coalition D is called maximally k-cohesive 
in R if \D\ < k, D is /c-cohesive and v(D) > v(D') for any D' C R. Suppose the 
operation max(I?, k) computes a maximally fc-cohesive set in R. The algorithm 
DGame(A, k) (Proc. [2]), which uses Cohesive(A, k) (Proc. [3]) as a subroutine, 
computes a fc-cohesive solution of Ga- Note that the Cohesive(_4, k) operation 
maintains a list D , which when returned, denotes a decomposition. Note also 
that the returned D = (D \,..., D m ) satisfies the following condition: 

VI < i < m : Di is maximally fc-cohesive in Di U • • • U D m 
We call this D a maximally k-cohesive decomposition. 

Lemma 15. Suppose D is a maximally k-cohesive decomposition. Take any 1< 
i <j < n. If v(Di U Dj) > max{t/(Di), p(Dj)} then Di U Dj is k-cohesive. 










Proof. Let Si = U i<j< m Dj for any i = 1 Suppose v(Di U Dj) > 

max{tfor 1 < i < j < to. By assumption Dj is maximally k- 
cohesive in S’,. For any finite set U C Dj U Dj C 5j such that |[/| < k, we have 
v{JJ) < v{Di) < v(Di U Dj). Hence Dj U Dj is also fc-cohesive. □ 

Theorem 16. Given an attribute primitive A, the DGame(_4, k) algorithm com¬ 
putes a k-cohesive solution of the decomposition game Gj i in time 0(n k ), where 
n is the number of requirements in A. 

Proof. The DGame(.A, k) algorithm calls Cohesive(„4, k) to produce a maximally 
fc-cohesive decomposition D , and then performs several iterations to “combine” 
the coalitions in D. By Lemma [T~5| the decomposition D after each iteration 
is fc-cohesive. There is a point when for all D,D' £ D we have v(D U D') < 
ma x{v(D),v(D')}. At this moment, the while-loop will terminate and D is 
expansion-free. The time complexity is justified as there are 0(n k ) subsets of 
F U S with size < k. Thus computing a maximally Dcohesive decomposition 
takes time 0 (n k ). □ 

5 Case Study: Cafeteria Ordering System 

To demonstrate applicability of our game 
model in real-world, we build a DG for a 
cafeteria ordering system (COS). A COS 
permits employees of a company to or¬ 
der meals from the company cafeteria on¬ 
line and is a module of a larger cafeteria 
management system. The requirements of 
the project have been produced through 
a systematic requirement engineering pro¬ 
cess and is well-documented (See full de¬ 
tails from [12. Appendix C]). Since COS 
is a subsystem within a larger system, the 
requirements also incorporate interfaces 
with other subsystems of the overall sys¬ 
tem. The initial attribute primitive has 60 
requirements with |S| = 11, |F| =49 and 
7 design constraints. Non-functional requirements conflict with each other, e.g., 
the general scenario USE conflicts with the general scenario PER. Also the re¬ 
quirements exhibit some complex relationships, e.g. SEC1 Order.Pay.Deduct. 

We demonstrate the complicated interactions among requirements using a 
complete graph where nodes are all requirements in R = S U F; see Fig. [3] 
The edges are in two colours: (ri,^) gets blue if w(r±, 7"2, R) > 0 and red if 
w(ri,r 2 , R) < 0. (For completeness, we include descriptions of constraints and 
requirements in the APPENDIX.) 

We run the DGame(A, k) algorithm to identify a fc-cohesive solution for dif¬ 
ferent levels k of expected cohesion. In order to clearly identify sub-components, 


Fig. 3. Interactions between require¬ 
ments in the COS m- Blue edges indi¬ 
cate positive interactions and red edges 
indicate negative interactions. 




we give a higher penalty A between conflicting requirements: a = 0.4, /3 = 0.3, 
7 = 0.3, A = —1.3. We choose k e {1,..7}. As argued above, setting a higher 
value of k should in principle improve the quality of the output decomposition, 
although this also means a longer computation time. We implement our algo¬ 
rithm using Java on a laptop with Intel Core i7-3630QM CPU 2.4GHz 8.0GB 
RAM. The running time for different values of k is: 503 milliseconds for k = 3 
and approximately 1140 seconds for k = 6 . 


Table 1. Resulting 3- and 6-cohesive solutions, ordered by payoff values. 



3-Cohesive Solution 

6-Cohesive Solution 

Coalition 0 

AVL1 ROB1 SAFI SEC(1,2,4) USE(1,2) 
Order.Confirm Order.Menu.Data 
Order.Deliver. (Select,Location) 
Order.Pay Order.Place Order.Retrieve 
Order.Units.Multiple UI2 UI3 

AVL1 ROB1 SAFI SEC(1,2,4) PER(1,2,3) 
USE(1,2) Order.Confirm Order.Deliver 
Order.Deliver. (Select,Location) 

Order.Menu.Date Order.Pay 

Order.Retrieve Order.Place Order.Units 
Order.Units.Multiple UI2 UI3 

Coalition 1 

PER(1,2,3) Order.Units.TooMany 
Order.Deliver. (Times,Notimes) 
Order. Place. (Cutoff, Data,Register,No) 
Order.Pay. (OK,NG) Order.Done.Failure 
Order. Confirm. (Prompt,Response, More) 

Order, pay. (Deliver,Pickup,Deduct) 
Order.Done.Patron SI2.2 SI2.3 

Coalition 2 

Order, pay. (Deliver,Pickup,Deduct) 
Order.Done.Patron SI2.2 SI2.3 

Order. Units. TooMany 

Order.Deliver. (Times, Notimes) 

Order. Place. (Cutoff, Data,Register,No) 
Order.Pay. (OK,NG) Order.Done.Failure 
Order. Confirm. (Prompt,Response, More) 

Coalition 3 

Order.Menu Order.Unit Order.Done 
Order. Done. (Menu,Times, Cafeteria) 
Order.Done. (Store,Inventory) 

Order.Deliver Order.Menu.Available 
Order. Confirm. Display 

Order.Pay.Method SI1.3 SI2.5 CI2 

Order.Done 

Order. Done. (Menu,Times, Cafeteria) 
Order.Done. (Store,Inventory) 

SI1.3 SI2.1 SI2.4 SI2.5 CI1 CI2 

Coalition 4 

SI1.1 SI1.2 

Order.Menu.Available SI1.1 SI1.2 


Cohesion level k = 3. The 3-cohesive solution consists of 5 coalitions. An 
examination at the requirements in each coalition reveals: Coalition 0 relates to 
usability and ensures availability of user interactions; it apparently corresponds 
to a user interface module. Coalition 1 is performance-oriented and is separated 
from the usability requirements; it thus corresponds to a back-end module that 
handles all the internal operations. Coalition 2 deals with the payroll system 
outside COS and defines a controlling interface from COS to payroll. Coalition 
3 consists of several functional requirements that control life cycle of the COS. 
Coalition 4 is an interface to access the inventory system outside COS. 

It is clear that this solution separates the control, user inputs and computa¬ 
tion modules, and fits the MVC (Model-View-Controller) architectural pattern. 
In addition, there is a design constraint that requires the use of Java and Oracle 
database engine. So, we instantiate the design elements as in Fig. [4] 










Fig. 4. The 3-cohesive solution. Coalition 0: Java Spring framework uses server page 
as user interface and provides a powerful encryption infrastructure (Spring Crypto 
Module). Server page is suitable for implementing interactive user interface. Coalition 
1: Enterprise Java Bean (EJB) is a middleware (residing in the application server) used 
to communicate between different components. It provides rich features for processing 
HTTP requests. Coalition 2: The COS uses a package solution from corresponding 
payroll system. Coalition 3: A servlet is a controller in Java application server which 
separates business logic from control. Coalition J: A web service interface outside COS. 
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Cohesion level k = 6. The 6-cohesive solution also contains five coalitions, with 
a similar structure as the 3-cohesive counterpart. There are, nevertheless, several 
important differences: Firstly, the performance (PER) scenarios now belong to 
coalitions 0. This means that some performance-related computation is moved 
to the front-end. This is reasonable as this lightens the computation load of 
the back-end and thus improving performance and availability. Secondly, the 
functional requirement Order.Menu.Available is moved to coalition 4, which is the 
interface between COS and the inventory system. This requirement specifies that 
the menu should only display those food items that are available in inventory. 

Instead of server page, we use scripting to reduce the server’s computation 
load. This can be achieved by changing the front-end to a JavaScript oriented 
designs. The main difficulty lies in that we need to put extra effort when using 
JavaScript to communicate with web server (such as AJAX) in order to ensure 
usability, performance and security. We instantiate design elements as in Fig. [5] 


6 Related Work 

Bass, Klein and Bachman introduce ADD as a general framework for develop¬ 
ing conceptual architecture in |4j. They argue that non-functional requirements 
should drive decision making throughout the entire design process. Furthermore, 
as non-functional requirements often provide a high-level view of a software 
system, ADD should follow an iterative decomposition process. They further 
improve their method in [T5] by clarifying how ADD is carried out in a real 
life project. The technique of evaluating tradeoff between quality attributes in 
these mentioned works is largely empirical-based. Kazman et. al. first investi- 












Fig. 5. The 6-cohesive solution. Coalition 0 uses JavasScript as a front end for user 
interface. It also takes some computation for sever in order to achieve better perfor¬ 
mance. Coalition 1 is an interface for accessing the payroll system. Coalition 2 ensures 
the business logic in COS. Coalition 3 coordinates input from front end (coalition 0) to 
back end (coalition 1). Coalition 4 is an interface for accessing the inventory system. 
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gate tradeoff between quality attributes in [7|. They collect and analyse design 
elements that affect multiple quality attributes. This approach aims to mitigate 
risks residing in a software architecture and refine design through this process. 
The study is further investigated in PjJ; which gives a quantitative tradeoff anal¬ 
ysis for non-functional requirements, and prioritises non-functional requirements 
during the ADD process. In p], a different approach is provided to elicit non¬ 
functional requirements. The work follows the paradigm in m but generates 
more detailed and concrete designs; it computes tradeoff between non-functional 
requirements based on relationships between non-functional and functional re¬ 
quirements. There are also other algorithmic methods for software architecture 
design from the perspective of component decomposition. For example, in [8], 
the authors propose a hierarchical clustering algorithm to decompose functional 
requirements and non-functional requirements. They label each component with 
a set of attributes and identify similarities between components based on their 
common attributes. Hence their approach does not put emphasis on the enhance¬ 
ment and conflict between attributes. 

7 Conclusion and Future work 

The use of computational games in software architecture design is a novel tech¬ 
nique aimed to contribute to this line of direction. We proposed a game-based 
approach that, not only builds on established software architecture research 
(ADD), but is also shown — through a case study — to provide reasonable 
design guidelines to a real world application. We suggest that this framework 
would be useful in the following: 

— Designing a software system that involves a large number of functionalities 
and quality attributes, which will result in a complicated architecture design 

— Designing a software system that hinges on the satisfaction of certain core 
quality attributes 












— Evaluating and analysing the rationale of an architecture design in a formal 
way; identifying potential risks with a design. 

It is noted that the framework described here assumes the completion of require¬ 
ment analysis. In real life requirements are usually identified as the software is 
implemented (e.g. the agile software development methodology). It would thus 
be interesting to develop a dynamic version of the game model, which supports 
architectural design using incremental refinements. Another future work is to 
develop a mechanism which maps coalitions generated by the algorithm to ap¬ 
propriate attribute primitives. This would then lead to a full automation of the 
ADD process linking requirements to conceptual architecture designs. 
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APPENDIX: Constraints and Requirements for COS 
Case Study 

Design Constraints 

— CO-2: The system shall use the current corporate standard Oracle database 
engine. 

— CO-3: All HTML code shall conform to the HTML 5.0 standard. 

— BR-2: Deliveries must be completed between ll:00anr and 2:00pm local time. 

— BR-3: All meals in a single order must be delivered to the same location. 

— BR-8: Meals must be ordered within 14 calendar days of the meal date. 

— BR-11: If an order is to be delivered, the patron must pay by payroll deduc¬ 
tion. 

— BR-33: 256-bit encryption or network transmissions that involve financial 
information 

Functional Requirements 

— Order.Place: Placing a meal order 

.Register. Confirm that the Patron is registered for payroll reduction. 
.No: If the patron is not registered for payroll deduction, the COS 
shall give the Patron options to register now and continue placing 
an order 

.Date: The COS shall prompt the Patron for the meal date (See BR-8) 

. Cutoff: If the meal date is today and is after the cutoff time, inform 
the Patron that it’s too late The Patron can either change the meal 
date or cancel the order. 

— Order.Deliver: Delivery or pickup 

.Select: The Patron specifies whether the order is to be picked up or 
delivered 

.Location: If the order is to be delivered and there are still available 
delivery times for the meal date, the Patron shall provide a valid delivery 
location. 

.Notimes: Notify the Patron if there are no available delivery times. The 
Patron shall either cancel or pick up the order in the cafeteria. 

. Times: Display the remaining available delivery times for the meal date, 
allowing the Patron to request one of the times shown 

— Order.Menu: Viewing a menu 

.Date: Display a menu for the date that the Patron specified. 

.Available: The menu for the specified date shall display only those food 
items for which at least one unit is available in the cafeteria’s inventory 
and which can be delivered 

— Order. Units: Ordering multiple meals and multiple food items 

.Multiple: Permit the user to order multiple identical meals 
. TooMany: If the Patron orders more units of a menu item than are 
presently in the cafeteria’s inventory, inform the maximum number of 
units that can order. 



Order. Confirm: Confirming an order 

.Display: When the Patron indicates no wish to order any more food 
items, display the ordered itrnes, prices, and the payment amount 
.Prompt: Prompt the Patron to confirm the meal order. 

.Response: The Patron can confirm, edit, or cancel the order. 

.More: Let the Patron order additional meals for the same or for a dif¬ 
ferent date. 

Order. Pay: Meal order payment 

.Method: When the Patron indicates that he is done placing orders, the 
COS shall ask the user to select a payment method 
.Deliver. Se BR-11 

.Pickup: If the meal is to be picked up in the cafeteria, the Patron shall 
choose to pay by payroll deduction or by cash at the time of pickup 
.Deduct: If Patron selects payroll deduction, issue a payment request to 
Payroll 

.OK: If the payment request is accepted, display confirmation a message. 
.NG: If the payment request is rejected, display the reason for the rejec¬ 
tions. 

Order.Done: Finishing the process after the Patron confirms the order 

.Store: Assign the next available meal order number to the meal and 
store the meal order 

.Inventory: Send a message to the inventory system with the number of 
units 

.Menu: Update the menu for the current order’s order date to reflect any 
items that are now out of stock in the cafeteria inventory 
. Times: Updates the remaining available delivery times for the date of 
this order 

.Patron: Send email message to the Patron with the meal order and 
payment info 

.Cafeteria: Send an email message to the Cafeteria Staff with the meal 
order information 

.Failure: If any step of Order.Done fails, roll back the transaction and 
notify the user 

User Interfaces 

• UI2: Provide a help link from each displayed webpage to explain how to 
use that page. 

• UI3: The webpages shall permit complete navigation and food item se¬ 
lection 

Software Interfaces 

• SI1.1: Transmit the quantities of food items ordered to the Cafeteria 
Inventory System through a programmatic interface. 

• SI 1.2: Poll the Inventory System to determine whether a requested item 
is available. 

• SI1.3: When the Cafeteria Inventory System notifies the COS that a 
specific food item is not available, the COS shall remove that food item 
from the menu for the current date. 



• CI1: Send an email or text message to the Patron to confirm order ac¬ 
ceptance 

• CI2: Send an email or text message to the Patron to report any problems 

Non-functional Requirement We have 6 general scenarios: USE, PER, SEC, 
SAF, AVL, ROB. Each of them associates multiple scenarios. 

— USEl: Allow a Patron to retrieve the previous meal ordered with a single 
interaction. 

— USE2: 95% of new users shall be able to order a meal without errors on their 
first try. 

— PERI: Accommodate 400 users and up to 100 concurrent users during the 
peak usage time, with an estimated average session duration of 8 minutes. 

— PER2: 95% of webpages generated shall download completely within 4 sec¬ 
onds from the time the user requests the page over a 20 Mbps or faster 
Internet connection. 

— PER3: Display confirmation messages to users within an average of 3 seconds 
and a maximum of 6 seconds after the user submits information to the 
system. 

— SEC1: All network transactions that involve financial information or person¬ 
ally identifiable info shall be encrypted per BR-33. 

— SEC2: Users shall be required to log on for all operations except viewing a 
menu. 

— SEC4'- The system shall permit Patrons to view only orders that they placed. 

— SAFI: The user shall be able to see all ingredients in any items, with allergic 
reactions. 

— AVL1: The COS shall be available at least 98% of the time between 5am 
and midnight and at least 90% of the time, excluding scheduled maintenance 
windows. 

— ROB1: If the connection between the user and the COS is broken prior to 
a new order being either confirmed or terminated, the COS shall enable the 
user to recover an incomplete order and continue working on it. 



